It is a bit unfortunate that from_local_timezone is a provided method, that can be overridden by other implementers of TimeZone. On such a type from_local_timezone may still panic, like currently with Local.

I think it is better to implement the conversion in NaiveDateTime::and_local_timezone, and let the methods on TimeZone use that.

Then we can guarantee that NaiveDateTime::and_local_timezone never panics because of this issue, independent of the type implementing TimeZone. And by using and_local_timezone in Datetime::map_local, all Datetime::with_* methods inherit that guarantee.

I also found a place in format/parsed.rs that had a workaround because of this panic, which is no longer necessary.

Codecov Report

Merging #1071 (e50dd89) into 0.4.x (c836a1f) will increase coverage by 0.01%.
Report is 2 commits behind head on 0.4.x.
The diff coverage is 83.33%.

@@            Coverage Diff             @@
##            0.4.x    #1071      +/-   ##
==========================================
+ Coverage   91.21%   91.23%   +0.01%     
==========================================
  Files          38       38              
  Lines       17121    17157      +36     
==========================================
+ Hits        15617    15653      +36     
  Misses       1504     1504              

... and 2 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

It is a bit unfortunate that from_local_timezone is a provided method, that can be overridden by other implementers of TimeZone. On such a type from_local_timezone may still panic, like currently with Local.

I think it is better to implement the conversion in NaiveDateTime::and_local_timezone, and let the methods on TimeZone use that.

Then we can guarantee that NaiveDateTime::and_local_timezone never panics because of this issue, independent of the type implementing TimeZone. And by using and_local_timezone in Datetime::map_local, all Datetime::with_* methods inherit that guarantee.

This was based on a wrong assumption.
Why would you ever want to do something different from simply subtracting the offset in TimeZone::from_local_timezone?
Answer: when implementing something like a Tai timezone, that should handle leap seconds differently.

So this is now back to a simple fix of the provided method TimeZone::from_local_timezone.

This no longer depends on other PRs.

Thank you for all your reviews!